I'm investigating an email problem that "solved itself" last week. Briefly, we run our own Exchange 2003 SMTP server, and every year or two, we see a condition where emails sent to one or two target domains fail. Exchange message tracking show retry...retry...retry..., then timeout and fail. After a couple weeks, with no obvious solution applied by anyone, everything is OK again. Our exchange server has an internal name "myserver.mycompany.com", and an external name "mail.mycompany.com", both of which appear in headers when we send a message. But dns only lists "mail.mycompany.com" because "myserver" is the internal name of the server. Has something been wrong with our exchange server for several years? Should email headers only show "mail.mycompany.com" and never reveal "myserver.mycompany.com"? If this is wrong, can somebod direct me to a document that describes what I should be doing? Note that failures are by retry and timeout and are infrequent. I'm guessing this is something that's incorrect, but usually tolerated by email servers. Here is a test message with rDNS failure and also rDNS lookup from another source. Obviously, the message DID get through, since I read it in the target account, but maybe the RDNS fail still tells us something useful? Here are headers from a message successfully received at my google account and originating from the the exchange server at mycompany.com: Delivered-To: mygoogleaccount@gmail.com Received: by 10.227.27.212 with SMTP id j20cs255311wbc; Sun, 20 Feb 2011 05:37:11 -0800 (PST) Received: by 10.229.235.143 with SMTP id kg15mr238910qcb.17.1298209029584; Sun, 20 Feb 2011 05:37:09 -0800 (PST) Return-Path: <mymailbox@mycompany.com> Received: from myserver.mycompany.com (mail.mycompany.com [###.###.###.###]) by mx.google.com with ESMTP id f10si8628230qcq.108.2011.02.20.05.37.07; Sun, 20 Feb 2011 05:37:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of mymailbox@mycompany.com designates ###.###.###.### as permitted sender) client-ip=###.###.###.###; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of mymailbox@mycompany.com designates ###.###.###.### as permitted sender) smtp.mail=mymailbox@mycompany.com Received: from [127.0.0.1] ([174.42.188.212] RDNS failed) by myserver.mycompany.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Feb 2011 08:51:49 -0500 OK, so somebody at 10.229.235.143 says "RDNS FAIL". I guess by that time it's inside of google (10....), so let's say google is the one saying "RDNS fail" But a rDNS test at mxtoolbox "OK - Reverse DNS matches SMTP Banner": From mxtoolbox.com, I asked for an SMTP test and got this: smtp:mycompany.com smtp 220 myserver.mycompany.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at Sun, 20 Feb 2011 08:34:36 -0500 OK - ###.###.###.### resolves to mail.mycompany.com, www.mycompany.com OK - Reverse DNS matches SMTP Banner 0 seconds - Good on Connection time Not an open relay. 0.437 seconds - Good on Transaction time Session Transcript: HELO please-read-policy.mxtoolbox.com 250 myserver.mycompany.com Hello [64.20.227.133] [62 ms] MAIL FROM: <supertool@mxtoolbox.com> 250 2.1.0 supertool@mxtoolbox.com....Sender OK [62 ms] RCPT TO: <test@example.com> 550 5.7.1 Unable to relay for test@example.com [156 ms] QUIT 221 2.0.0 myserver.mycompany.com Service closing transmission channel [47 ms] And I also tried a rDNS from mxtoolbox; this looks like what I'd expect: ptr:###.###.###.### ptr Type IP Address Domain Name TTL PTR ###.###.###.### www.mycompany.com 24 hrs PTR ###.###.###.### mail.mycompany.com 24 hrs reverse lookup smtp diag port scan blacklist Reported by 24.30.200.19 on Sunday, February 20, 2011 at 7:27:51 AM (GMT-6)

When it comes to PTR as a antispam feature, the only thing that matters is the last hop between your server and the external server. What happens before and after doesn't really matter. So your email could go through other servers which have internal names on them, and that doesn't matter. As long as the connection out is coming from a public host name which ideally matches the PTR, then email will be successful. The RDNS failed indication on the first line of the header (you read headers up) looks like an internal thing. Have you got reverse DNS lookup enabled on the Exchange 2003 SMTP server? IF so, you may as well disable it as Exchange cannot do anything about the results other than mark it on the headers. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Thanks, Simon. It sounds like the RDNS FAIL is meaningless in this case, but I need to check out the Exchange server's rDNS settings at mycompany.com. (Simon from the UK, eh?) When it comes to PTR as a antispam feature, the only thing that matters is the last hop between your server and the external server. What happens before and after doesn't really matter. So your email could go through other servers which have internal names on them, and that doesn't matter. As long as the connection out is coming from a public host name which ideally matches the PTR, then email will be successful. When I check with mxtoolbox it says "OK - Reverse DNS matches SMTP Banner", so it looks like the outside world likes the server at mycompany.com. That and the fact the test message got to its destination seem consistent. The RDNS failed indication on the first line of the header (you read headers up) looks like an internal thing. Yep, it is. If I inspect the first line (bottom, reading up--thank you--I read it wrong earlier) where I see the RDNS failure... Received: from [127.0.0.1] ([174.42.188.212] RDNS failed) by myserver.mycompany.com I see that myserver.mycompany.com reported RDNS failure for the place where it got the message from. Which was my laptop at my house. And 174.42.188.212 was the IP alltel assigned me at my house at the time sent the message. Have you got reverse DNS lookup enabled on the Exchange 2003 SMTP server? IF so, you may as well disable it as Exchange cannot do anything about the results other than mark it on the headers. I don't know; I'll check it out and find out the correct way to turn it off. (I don't want to become an open relay with no authentication!). Right now, I DO know that we require authentication to relay from outside the domain (maybe from inside, too? I haven't tried it). So--sure--why would we need rDNS also? Maybe rDNS fail lets Exchange know "nope--he's outside the domain' make him authenticate". So, I will be careful to understand it before I start messing with it. But surely it is meaningless and confusing to put "RDNS FAIL" in the headers AFTER the deciding it's OK to send the message out the door!

The Reverse DNS lookup setting on Exchange 2003 is completely useless. It has no effect on the operation of Exchange. Nothing to do with relaying, authentication or anything. All it does is slow down the email delivery slightly while the lookup takes place. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Thanks very much for confirming that's OK to turn off. I'd already gone back to the office yesterday and read up on it, then turned off rDNS in our SMTP virtual server. Seemed to work (the bogus errors went away), but I worry about what I might knock over when I'm poking around! Also put mail.mycompany.com in our banner. Why should anybody on the outiside world see our internal server name? They shouldn't and now they don't.